I've reviewed the wonderful wiki documentation [Wiki Link] and skimmed through the pull request related to the proposed changes for the SDK. Based on my understanding it seems the proposal aims to address several objectives:

• Enable safe contributions of external packages to the SDK by external developers.
• Facilitate workload distribution between different subteams within the SDK development process.
• Potentially introduce a mechanism for deprecating SDK features.

Complexity Concerns: While I appreciate the potential benefits of these changes, I'm concerned that the proposed solution might lead to an increase in overall SDK development complexity in the near future. Personally, I would prefer to minimize such complexity.

Before moving forward with this specific proposal, I believe it would be valuable to take a step back and identify the most pressing challenges we need to address for the SDK's future development. By focusing on the core problems, we can potentially explore alternative solutions that achieve our goals without introducing unnecessary complexity.

I'd be happy to discuss this further and collaborate on defining a clear roadmap for the SDK's future.

Complexity Concerns: While I appreciate the potential benefits of these changes, I'm concerned that the proposed solution might lead to an increase in overall SDK development complexity in the near future. Personally, I would prefer to minimize such complexity.

I'd like hear this concern about complexity. I think its much simpler to operate in a bunch of micro / smaller packages (although there is acknowledged organic overhead of just doing more than a single package) than to deal with a single monolithic SDK package. You get versioning, the ability to do small breaking changes, run a small subset of tests, and the flexibility to do a lot more things than having to worry about changes to code in other areas of the codebase.

Breaking things up is always a tough thing to do, but in fact we really aren't overtly breaking this up for the sake of breaking things up. In fact, I wouldn't really even consider this breaking up the SDK, more about enforcing strong boundaries been modules where that doesn't exist at all currently.

To be 100% clear, there are no required or mandatory near future changes. SDK3 can be developed as SDK3 (this PR makes no impact on it). Any of these changes can be back-ported to SDK3 also.

Happy to discuss, but the main objective is to organically move things over in time to assist to getting an SDK4.

Before moving forward with this specific proposal, I believe it would be valuable to take a step back and identify the most pressing challenges we need to address for the SDK's future development.

If you feel there is a pressing need somewhere else, please create a proposal and execute on it and we can compare then.